The present invention relates to computing systems and more particularly to client-server systems, including but not limited to distributed client-server systems.
In a distributed client-server system, a client program often requires an intermediary to perform an operation on some server. The intermediary must be able to convince the server that it is operating on behalf of the client and hence that it should be granted the right to perform the requested operation. Furthermore, to limit exposure to untrusted intermediaries, the client will want to grant to the intermediary only that subset of its rights that are necessary for completing the requested operation.
An example of such a situation is the use of a print server to print a file that resides on a file server. The initiating user would like to grant the print server access to the file to be printed so that it can directly retrieve the file from the file server. However, the user would like to prevent the print server from being able to retrieve any other files. The user might also wish to place a time limit on how long the print server has access rights to the file.
A second example is remote compilation on a compute server. The compute server must be given read access to all the relevant source files. It should also be permitted to create or overwrite the relevant object files while being prevented from modifying source files. Additionally, suppose the compute server does a recompilation as a set of parallel tasks, each running on a separate machine. Then the server will want to delegate some of the rights it has acquired to other hosts that are performing subtasks.
This example can be further complicated if the files and directories involved are owned by someone other than the user who is invoking the compilation. The user (e.g., as member of a group) may have permission to read and write various files in a directory, but may lack permission to modify the access controls of those files or the directory they are in. Hence it may not even be possible for the user to delegate access rights to a third party.
A more application-specific example is a self-paced course in which students submit their homework assignments by creating a file in a well-known directory. The solutions to each homework assignment also reside in files in that directory; however, each student should only be given access to the solutions after they have handed in their answers for that assignment. The access control specification in this case is that only students in the class may read or write files in the directory, no student in the class may read a solution file without having already written a corresponding homework file and no student may write any given homework file more than once.
Finally, one may wish to limit access to resources that can be subdivided, such as electronic funds. This implies being able to specify quantitative limits on resources for which access rights have been delegated.
Techniques proposed in the prior art for granting/delegating access control have centered around access control lists and capability schemes. Access control lists (ACLs) are lists of (name, access right) tuples. Such lists may be implemented as bit tables, linked lists, or other suitable data structures. Servers maintain ACLs and use them to decide whether or not to grant any given access request. Capability schemes are based on capability tokens that servers hand out to clients. A requestor, such as an intermediary between a client and a server, presents a capability token along with an access request to prove that the requestor has the right to make the request of the server.
Both ACL- and capability-based systems provide ways for a client to delegate its access rights to an intermediary, but provide only limited facilities for restricting the rights granted to the intermediary. ACL-based systems can deal with restricted delegation by allowing the creation of roles, which explicitly represent the entity to whom a restricted set of access rights is being delegated. Capability-based systems enable restricted delegation by either handing out multiple tokens or by handing out tokens that can be securely subsetted to a certain degree. Both of these approaches to restricted delegation depend on servers' having an explicit understanding of all access controls: Concepts such as restrictions over file types, access time limits, the homework example restrictions, or resource quotas must be implemented at the servers. Servers must know in advance of any client requests all the various access rights and restrictions that clients may want to delegate.
With either ACL- or capability-based systems, if a client wishes to enforce access controls that are not understood by the server(s) available to him, he has only one option, namely, to use or build other servers. For example, consider a distributed file system that does not ordinarily support access time limits. An example is the Unix distributed file system known as NFS, which is described, for example, in Russell Sandberg, David Goldberg, Steve Kleiman, Dan Walsh, and Bob Lyon, "Design and Implementation of the Sun Network File System," in Proceedings of the Summer 1985 USENIX Conference (Portland, Ore., June 1985) at 119-130. To build a print service that understands access time limits on NFS files requires that a new print server be built that both understands time-limit-based access controls and is trusted with access to all NFS files that any clients might wish to print. Similarly, to implement the homework example on top of prior art file servers (or any file servers whose access controls lack the concepts necessary to express the homework constraints) requires that someone build a "homework server." Furthermore, students' ability to hand their homework in and receive solution sets back depends on the availability of this homework server.
To better understand the limitations of the prior art, it is helpful to consider an analogy. Suppose that a movie theater shows ten different movies. Some are suitable for viewers of all ages, while others are suitable only for adults. Like most movie theaters, this theater sells tickets separately for each individual movie. A patron who holds a ticket for, say, "Gone With the Wind," is thereby entitled to see "Gone With the Wind" but is not entitled to see "Jaws" or "Unforgiven" or any other movie playing at the theater.
Now suppose that a parent wishes to send her child, who is thirteen years old and not to be trusted, to see a movie unaccompanied. The parent wants the child to see only "Grated" movies, that is, movies deemed suitable for viewers of all ages, and no other movies. She is concerned that if she simply gives the child money to purchase a ticket, left to his own devices the child (possibly with the assistance of an adult or older teenager posing as his "guardian") will purchase a ticket to an "R-rated" movie intended for more mature viewers. Thus the parent runs the risk that if she tells her child to go see "Bambi," the child will sneak in to see "Basic Instinct." What the parent really wants is to be able to purchase in advance, and give to her child, a movie ticket redeemable for access to any G-rated movie and for no other movies. Unfortunately the movie theater does not sell such tickets. Short of persuading the movie theater to change its ticket-selling policies, the parent is stuck with either having to accompany her child to the theater or else running the risk that the child will disobey her.
It can be seen that the parent is analogous to a client program, the child to an intermediary, the movie theater to a server, and the movie ticket to a capabilities token in a capability-based system. The parent-client is stuck with the kind of tickets that the theater-server sells, and cannot order a custom-made ticket that would allow her to grant some independence to her intermediary-child while simultaneously maintaining a certain measure of control over the intermediary-child's behavior. The system provides no straightforward way for a client to design a restricted set of access privileges, e.g., at run time, and delegate these to a potentially untrustworthy intermediary.
What is needed as an alternative to embedding an ever-increasing multitude of access control concepts into each server or building an ever-increasing set of application-specific "front-end" servers is to provide clients and servers with a language with which they can dynamically build generalized capabilities and define application-specific access rights at the time those rights are to be delegated.